GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

</head>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p><b>EBPP</b> ist die <a href="Abk%C3%BCrzung" title="Abkürzung">Abkürzung</a> für <i><b>e</b>lectronic <b>b</b>ill <b>p</b>resentment and <b>p</b>ayment</i> („elektronische Rechnungsstellung und -bezahlung“). Hierbei kann es sich um eine auf <a href="E-Mail" title="E-Mail">E-Mail</a> basierende Lösung bis hin zu einem kompletten, elektronischen Zahlungssystem handeln.

</p><p>Man unterscheidet bei EBPP-Systemen folgende Kriterien und Funktionalitäten:

</p>

<ul><li><i>Format der Rechnungsdaten</i>

<ul><li>strukturiert: <a href="Extensible_Markup_Language" title="Extensible Markup Language">XML</a>, <a href="Webschnittstelle" class="mw-redirect" title="Webschnittstelle">Web Interface</a>, <a href="EDIFACT" title="EDIFACT">EDIFACT</a> etc.</li>

<li>nicht strukturiert (nicht automatisiert weiterverarbeitbar): <a href="PDF" class="mw-redirect" title="PDF">PDF</a>, <a href="Tagged_Image_File_Format" title="Tagged Image File Format">TIFF</a>, <a href="JPEG" title="JPEG">JPEG</a> etc.</li></ul></li>

<li><i>Bill presentment</i> – Präsentation der Rechnung</li>

<li><i>Bill payment</i> – Bezahlungsmöglichkeit</li></ul>

<p>Weiterhin lassen sich zwei verschiedene <a href="Modell" title="Modell">Modelle</a> des EBPP unterscheiden:

</p>

<ul><li>das <i>Direct Billing</i> Modell</li>

<li>das <i>Consolidator</i> Modell</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Direct_Billing_Modell">Direct Billing Modell</h2></div>

<p>Das rechnungsstellende Unternehmen bietet bei diesem Modell den eigenen Kunden den Service, Rechnungen elektronisch entweder per E-Mail oder über einen geschützten Bereich der eigenen <a href="Webseite" title="Webseite">Webseite</a> unter <a href="Login_(Informationstechnik)" title="Login (Informationstechnik)">Anmeldung</a> mit Benutzername und <a href="Passwort" title="Passwort">Passwort</a> zu betrachten.

</p><p>Direct Billing (auch E-Billing genannt) bezieht sich hier auf die direkte Beziehung zwischen Unternehmen und <a href="Kunde" title="Kunde">Kunde</a>.

</p><p>Vorteile:

</p>

<ul><li>Die Kunden können innerhalb des eigenen Systems jegliche technisch möglichen Aktionen durchführen (z. B. Anmeldung zu weiteren Services, Zugriff auf Detaildaten etc.)</li>

<li>Zugriff auf Rechnungsdaten in Echtzeit möglich (Hot Billing)</li>

<li>größtmögliche Flexibilität</li></ul>

<p>Nachteile:

</p>

<ul><li>hohe Implementierungskosten</li>

<li>hoher Wartungsaufwand</li>

<li>generell geringe Akzeptanz bei Endkunden, bedingt durch Zugangsdaten (mindestens URL, Username, Passwort)</li></ul>

<p>Viele Unternehmen aus den Branchen <a href="Telekommunikation" title="Telekommunikation">Telekommunikation</a>, <a href="Internetdienstanbieter" title="Internetdienstanbieter">Internetdienstanbieter</a> und <a href="Energieversorgungsunternehmen" title="Energieversorgungsunternehmen">Energieversorgung</a> haben in den letzten Jahren eigene Direct Billing Lösungen für ihre Kunden entwickelt. Durch die generell schwache <a href="Akzeptanz" title="Akzeptanz">Akzeptanz</a> der <a href="Verbraucher" title="Verbraucher">Verbraucher</a> von durchschnittlich 3–8 % je Branche wird der direkte Zugang zu den Endkunden zunehmend in Frage gestellt.

</p>

<div class="mw-heading mw-heading2"><h2 id="Consolidator_Modell">Consolidator Modell</h2></div>

<p>Anstelle der direkten Verbindung von Rechnungssteller und Rechnungsempfänger werden die Rechnungen auf einer neutralen Plattform zusammengefasst, <a href="Aggregation_(OLAP)" title="Aggregation (OLAP)">konsolidiert</a>. Der Rechnungsempfänger kann diese Plattform somit für alle an diesem Consolidator teilnehmenden Rechnungssteller nutzen und über einen Zugang abrufen.

</p><p>Ist der Consolidator in eine bestehende <a href="Infrastruktur" title="Infrastruktur">Infrastruktur</a>, wie beispielsweise das <a href="Electronic_Banking" title="Electronic Banking">Electronic Banking</a> eines <a href="Kreditinstitut" title="Kreditinstitut">Kreditinstituts</a>, integriert, so können die Rechnungsempfänger dieses Service zumeist ohne zusätzliche Zugangsdaten nutzen.

</p><p>Vorteile:

</p>

<ul><li>Neue Teilnehmer, Rechnungsempfänger sowie Rechnungssteller, können den schon bestehenden Kundenstamm des Consolidators nutzen</li>

<li>Service als <a href="Webservice" title="Webservice">Webservice</a> nutzbar, zumeist keine hohen Einstiegskosten</li>

<li>Weiterentwicklung übernimmt der Betreiber der Consolidator Plattform</li>

<li>Haftung für rechtliche Aspekte, wie z. B. <a href="Umsatzsteuergesetz_(Deutschland)#Vorsteuerabzug" title="Umsatzsteuergesetz (Deutschland)">Vorsteuerabzugsfähigkeit</a>, übernimmt der Betreiber der Consolidator Plattform</li>

<li>Multiplikatoreffekt: Werbemaßnahmen von Rechnungsstellern zur Teilnahme von deren Kunden schlagen auf alle anderen Rechnungssteller über</li></ul>

<p>Nachteile:

</p>

<ul><li>Geringere Flexibilität, da Standardformate des Consolidators unterstützt werden müssen</li>

<li>Hot Billing zumeist nicht möglich</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Gesetzliche_Rahmenbedingungen">Gesetzliche Rahmenbedingungen</h2></div>

<p>Damit eine <a href="Elektronische_Rechnung" title="Elektronische Rechnung">elektronische Rechnung</a> im gleichen Sinne wie eine papierhafte Rechnung zum Abzug der <a href="Vorsteuer" class="mw-disambig" title="Vorsteuer">Vorsteuer</a> berechtigte, musste diese in Deutschland bis 2011 (vgl. <span class="-print"><a rel="nofollow" class="external text" href="https://www.buzer.de/s1.htm?g=UStG+01.07.2011&a=14">§ 14</a><span style="display:none"></span></span> UStG a. G.) über eine <a href="Qualifizierte_elektronische_Signatur" title="Qualifizierte elektronische Signatur">qualifizierte elektronische Signatur</a> im Sinne des <a href="Signaturgesetz_(Deutschland)" title="Signaturgesetz (Deutschland)">Signaturgesetzes</a> verfügen. Seit dem 1. Juli 2011 sind in Deutschland gemäß Steuervereinfachungsgesetz 2011, mit dem die <a href="Richtlinie_(EU)" title="Richtlinie (EU)">EU-Richtlinie</a> <span class="-print"><a rel="nofollow" class="external text" href="https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32010L0045">Richtlinie 2010/45/EU</a></span> umgesetzt wurde, <b>elektronische Rechnungen</b> und klassische Papierrechnungen gleichgestellt, um <a href="Gesch%C3%A4ftsprozess" title="Geschäftsprozess">Geschäftsprozesse</a> einfacher und <a href="Wirtschaftlichkeit" title="Wirtschaftlichkeit">wirtschaftlicher</a> zu machen. In Österreich gelten die Bestimmungen ab 1. Januar 2013. Eine qualifizierte elektronische Signatur ist damit seit 2011 nicht mehr das einzige Sicherungsverfahren für elektronische Rechnungen. Neben den technischen Verfahren (Signatur und EDI/EDIFACT) ist als organisatorisches Verfahren der sog. verlässliche Prüfpfad (<a href="Audit_Trail" title="Audit Trail">audit trail</a>) zulässig. Wann welches Verfahren zum Einsatz kommt, hängt von der Art der Geschäftsbeziehung und den praktischen Möglichkeiten der Verifikation von Identitätsinformationen (vgl. <span class="-print"><a rel="nofollow" class="external text" href="https://www.buzer.de/s1.htm?g=GwG&a=11,12">§§ 11 und 12</a><span style="display:none"></span></span> des <a href="Geldw%C3%A4schegesetz" class="mw-redirect" title="Geldwäschegesetz">Geldwäschegesetzes</a>) über den Vertragspartner ab.<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Praxis">Praxis</h2></div>

<p>In der Praxis werden Rechnungen zunehmend als PDF-Datei im Anhang einer E-Mail übermittelt. Der Rechnungsempfänger druckt sie aus und legt sie wie jede andere papiergebundene Rechnung ab. Da Rechnungen in Deutschland (anders als in anderen europäischen Ländern üblich) in der Regel nicht unterschrieben werden, kann der ausgedruckten Rechnung dann nicht mehr angesehen werden, dass sie einmal eine elektronische Rechnung war. Steuerrechtlich ist ein solches Vorgehen jedoch unzulässig.

</p><p>Das Risiko bei der Umsatzsteueraußenprüfung ist jedoch nicht, dass der Prüfer die Belege daraufhin überprüft, ob diese ausgedruckt wurde oder evtl. doch elektronisch übermittelt worden sind.

</p><p>Die Prüfung geht immer vom versendenden Unternehmen aus. D. h. bei einer Außenprüfung im versendenden Unternehmen wird festgestellt, dass elektronische Rechnungen ohne eine qualifizierte Signatur im Sinne des <span class="-print"><a rel="nofollow" class="external text" href="https://www.buzer.de/s1.htm?g=SigG_2001&a=2">§ 2</a><span style="display:none"></span></span> Nr. 3 SigG oder Rechnungen, welche den Anforderungen gemäß <span class="-print"><a rel="nofollow" class="external text" href="https://www.gesetze-im-internet.de/ustg_1980/__14.html">§ 14</a></span> UStG nicht entsprechen, erstellt wurden. Dies ist leicht feststellbar, da jedes Unternehmen eine <a href="Aufbewahrungspflicht" class="mw-redirect" title="Aufbewahrungspflicht">Aufbewahrungspflicht</a> nach den <a href="Grunds%C3%A4tze_ordnungsm%C3%A4%C3%9Figer_DV-gest%C3%BCtzter_Buchf%C3%BChrungssysteme" title="Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme">Grundsätzen ordnungsmäßiger DV-gestützter Buchführungssysteme</a> trifft. Daraufhin macht das Finanzamt eine Quermitteilung an alle betroffenen Veranlagungsfinanzämter, dass formungültige Belege an den Empfänger versendet wurden.

</p><p>Im Ergebnis führt dies dazu, dass der <a href="Au%C3%9Fenpr%C3%BCfung" title="Außenprüfung">Außenprüfer</a> beim Empfänger ins Haus kommt und die elektronisch übermittelten Belege schon kennt. Er überprüft dann nur noch, ob der Empfänger seiner Verpflichtung aus <span class="-print"><a rel="nofollow" class="external text" href="https://www.gesetze-im-internet.de/ustg_1980/__15.html">§ 15</a></span> UStG nachgekommen ist und die ohne Signatur übermittelten Rechnungen ausgesondert hat. Hat der Empfänger jedoch aus diesen elektronischen Rechnungen die enthaltene Vorsteuer zum Abzug gebracht, ohne dass die Voraussetzungen des § 15 UStG vorgelegen haben, werden diese Vorsteuerbeträge zurückgefordert.

</p>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li>ibi research an der Universität Regensburg GmbH: <a rel="nofollow" class="external text" href="http://www.elektronische-rechnungsabwicklung.de/marktueberblick.html">Rahmenbedingungen und Marktüberblick</a> auf elektronische-rechnungsabwicklung.de</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text">Aufsatz, Kirmes, <style data-mw-deduplicate="TemplateStyles:r261891140">

/* start https://de.wikipedia.org/ */

.mw-parser-output .webarchiv-memento a{color:inherit}

/* end https://de.wikipedia.org/ */

</style><a rel="nofollow" class="external text" href="https://web.archive.org/web/20140322213040/http://www.rechnungsaustausch.org/rechtliches/kirmes-liberalisierung-sicherungsvorschriften.pdf"><i>Zum Stand der Liberalisierung von Sicherungsvorschriften für Elektronische Rechnungen</i>.</a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 22. März 2014 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>) (PDF; 506 kB) In: <i>Die Steuerberatung</i> (Stbg), 7/2011, S. 299–310.</span>

</li>

</ol>

<div>

Bitte den Hinweis zu Rechtsthemen beachten!</div>

</div></div></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2024-12-21" href="https://de.wikipedia.org/wiki/?title=EBPP&oldid=251439338">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>